Feat: Body Parsing #53
Conversation
|
|
||
| // Extract the command from the body | ||
| signal command_reveal[max_command_bytes]; | ||
| component select_command_sub_array = SelectSubArray(max_body_bytes, max_command_bytes)(padded_body, command_idx, command_len); |
There was a problem hiding this comment.
Where is a definition of SelectSubArray?
I expect that it extracts a substring from command_idx to command_idx + command_len, but it has an attack vector because a relayer can choose any substring in the email body.
To prevent this, the circuit first needs to do a regex validation of padded_body for the regex <div id="zkemail">[^<>\r\n/]</div> and gets a revealed string for [^<>\r\n/] as command_reveal.
There was a problem hiding this comment.
It implies that an input command_len is unnecessary.
| // * max_command_bytes - max number of bytes in the command | ||
| // * recipient_enabled - whether the email address commitment of the recipient = email address in the subject is exposed | ||
| // * is_qp_encoded - whether the email body is qp encoded | ||
| template EmailAuthWithBodyParsing(n, k, max_header_bytes, max_body_bytes, max_command_bytes, recipient_enabled, is_qp_encoded) { |
There was a problem hiding this comment.
is_qp_encoded
Can we fix the value of is_qp_encoded when operating the service?
Or do we need to deploy two circuits and choose which circuit is used for each email?
There was a problem hiding this comment.
The second option, because the flag will be turned on for email with big commands (which have soft-line breaks) and should be turned off for small ones as the proving time improves.
There was a problem hiding this comment.
Do you think a malicious relayer can choose an inappropriate circuit, which can be an attack vector?
There was a problem hiding this comment.
If the reason to turn off the flag is only for efficiency, I think we can always use a circuit with soft-line breaks.
There was a problem hiding this comment.
I don't see any attack surface here as the regex just won't pass if you send a body with QP encoding but don't remove those in the circuit. We can do the swapping thing imo
packages/circuits/src/email_auth_with_body_parsing_with_qp_encoding.circom
Outdated
Show resolved
Hide resolved
…l/ether-email-auth into feat/body-parsing-circuit
…to feat/body-parsing-circuit
…to feat/body-parsing-circuit
…l/ether-email-auth into feat/body-parsing-circuit
…l/ether-email-auth into feat/body-parsing-circuit
…l/ether-email-auth into feat/body-parsing-circuit
|
Shifted commits to #59 |
Body Parsing Circuit Implementation
Changes
email_authcircuit with body parsing functionality